1. Field of the Invention
This invention relates to the fields of distributed computing systems, client-server computing and object oriented programming. More specifically, the invention is a method and apparatus for providing program developers and users the ability to debug target applications which may include programs or objects on distributed servers.
2. Background
It is essential that a computer application developer be able to debug the application he is creating. This becomes an exceedingly difficult problem in an object-oriented, distributed processor environment. Such modern environments include applications which invoke objects developed by persons other than the application developer and may include implementations of the objects which are running on a processor remote from and unknown to the application developer. Nevertheless the application developer must have a way to debug the portions of the application that might reside on such remote and unknown processors.
For example, a distributed application is an application that comes in two or more parts. Those parts are often referred to as a client and its servers. Distributed applications have been in existence for many years and for just as many years program application developers have had the problem of debugging distributed applications. The typical method for debugging a distributed program is to start the client under a debugger and debug the client until one gets to a function that is in a server. If the developer is lucky, the server is already running on a known host. The developer then goes to the server host, identifies the server process, attachs a debugger to it, and continues the debugging session. If the server is not running yet, the developer must figure out how to get the server running and hope that whatever he did does not obscure the bug he/she is hunting. Once the server has been started the developer again attachs a debugger to it. Or the developer has to figure out how to interpose on the startup of the server so that he/she can attach a debugger to the server before anything interesting happens. This method is error prone, laborious, often confusing and tedious.
In an object oriented system, an object is a component comprising data and operations which can be invoked to manipulate the data. The operations (also called "methods") are invoked on the object by sending calls to the object. Each object has an object type that defines the operations that can be performed on objects of that type. One object type may inherit the object operations defined and implemented for other object types. For further description of object oriented design and programming techniques see "Object-oriented Software Construction" by Bertrand Meyer, Prentice-Hall 1988.
In client-server computing, typically there is a set of computers that can communicate with one another through a network connecting the computers. Some of these computers act as providers of services or functionality to other computers. The providers of a service or functionality are known as "servers", and the consumers of the service or functionality are called "clients". The client-server model also generalizes to the case where distinct programs running on the same computer are communicating with one another through some protected mechanism and are acting as providers and consumers of functionality.
In object oriented distributed systems based upon the client-server model, there exist servers that provide object oriented interfaces to their clients. These servers support objects consisting of data and the associated software for manipulating the data according to the operations permitted by this type of object. Clients may obtain access to these objects and may execute calls on them by transmitting the calls to the server. At the server these calls are executed via the software associated with the object. The results of these calls are then transmitted back to the client.
Another fundamental problem with prior art debuggers arises when one is faced with debugging an application which is implemented in a modern day distributed object system. Consider a Distributed Objects system of the type generally specified by the Object Management Group ("OMG"). OMG is a collection of over 500 companies which have agreed to certain specifications and protocols for such a distributed object system. The basic specification for this system is contained in the OMG Document Number 93.xx.yy Revision 1.2 dated Dec. 29, 1993 titled "The Common Object Request Broker: Architecture and Specification" (otherwise referred to as CORBA) which is incorporated herein by reference. Such CORBA compliant systems provide for building applications with pre-existing objects. Such applications can request the creation of an object and perform operations on that object. The creation and operations on objects are performed by servers for those objects. If such an application wants to create an object, it transparently utilizes a locator mechanism which finds a server known as a "factory" for that object. Similarly if such an application has a preexisting object, it transparently utilizes a locator mechanism to find a server that can perform operations on that object.
In such CORBA compliant systems there is a considerable amount of mechanism behind each object that allows the application programmer to use objects without knowledge of where the servers for the objects run. In the special circumstance where the developer of the client is also the developer of the server, arrangements can be made such that the programmer will know where the servers will run and what their names are. In general, however, the CORBA compliant system applications developer will be unable to locate the servers associated with his objects. Thus there exists a need to support debugging of objects used by applications regardless of whether the object is located in the same or remote process and regardless of where the object is. Moreover this debugging procedure should preferably create a "single process" illusion to the developer to allow the debugging of a large distributed application using a familiar debugging paradigm.
A major shortcoming of certain prior art debuggers is that they require a large overhead of supporting data and processes, usually comprising additional data generated by related compilers. Therefore a preferred embodiment for a remote debugger requires that object implementors should not have to do anything special to make their objects "debuggable" other than compile their servers so that symbolic information is generated. (In C and C++ using the -g compiler option.). However no additional behavioral or data abstractions on either servers or servant should be required lest the related overhead dominate the size and performance of fine grained objects. Similarly, another limitation of the prior art debugging systems is that they are linked to a specific type of target application and/or a specific compiler language. It is desired to have a distributed debugger be able to debug applications independent of the implementing language. That is, the preferred distributed debugger should not require any assumptions about the kinds of servers and objects it may operate on or operate with. The CORBA specification describes a variety of "Object Adapters" which may be used to service different kinds of object implementations. The desired distributed debugger should operate in an "Object Adaptor" independent manner if it indeed need not make any assumptions about the kinds of servers or objects it can operate with. Furthermore it is desired to have a distributed debugger that can ignore any boiler-plate code which the implementation of the CORBA compliant system might use to facilitate the operation of the system. "Boiler-plate" code refers to any non-programmer-generated code produced by the development environment and which is unknown to the developer. The distributed debugger should allow the developer to debug his system at the same functional level of abstraction at which they implemented the system.
The distributed debugger of the present invention, designated the "doeDebugger", provides an apparatus and method for accomplishing distributed debugging in a seamless, low-overhead, unencumbered manner, thereby permitting a developer to debug a distributed object oriented application with the illusion that he is debugging a "single process" application.